Most business enterprises today depend on an enterprise communication network (“enterprise network”) for successful day to day operation. In this context, an enterprise network may be defined as any communications network under the control of a single organization. Enterprise networks often include geographically dispersed networking devices and other resources. An enterprise network may use multiple, varied networking protocols, employ different types of forwarding devices, connect computer systems from different vendors, and be relied on by numerous enterprise level application programs.
With the globalization of the economy, enterprise networks are increasingly used to interconnect sites in multiple geographic locations. For example, enterprise networks may employ a number of internal data and voice networks to provide connectivity within sites, and interconnect those sites by way of the Internet or leased lines. The organization may obtain service level agreements (SLAs) with one or more Internet/leased-line connectivity providers for its inter-site communication needs. At the present time, such SLAs mainly consist of agreements on the amount of bandwidth to be provided between specific sites, and network uptime requirements. Enterprise networks often include diverse types of communication networks, portions of which use different protocols for data forwarding. For example, a portion of an enterprise network may operate using switching forwarding devices, while another portion may operate using routing forwarding devices, etc. Such portions of the enterprise network are referred to herein as “forwarding domains”.
Today's enterprise networks are used by an ever widening variety of software and hardware applications. Each business uses a set of applications that uniquely fits its particular needs. Enterprise applications require connectivity over the enterprise network, in order to operate properly and to offer application services to users throughout the enterprise. To provide enterprise-wide application connectivity, many different network types and interfaces are used, such as Ethernet, POS (Packet over SONET), ATM (Asynchronous Transfer Mode), and/or many others. Using these varied systems, enterprise network performance has steadily improved in terms of providing connectivity within the enterprise. However, enterprise wide connectivity in itself is insufficient to completely meet the needs of many enterprise applications. Unfortunately, from the perspective of today's enterprise application computer programs, existing enterprise networks simply connect end points within the enterprise so that the application can run. Applications relying on the enterprise network often have no convenient control over the operation of the network in terms of how the enterprise network treats application data packets on an end to end basis across the enterprise. Under these circumstances, enterprise applications can only rely on the enterprise network to provide basic end to end connectivity, without the ability to specify other aspects of the service they receive from the enterprise network.
Network service requirements of individual enterprise applications can be quite different. One enterprise application might require a relatively small end to end delay, and continue to operate properly in the face of some percentage of packet loss (e.g. Voice over IP), while another enterprise application might need a constantly fixed bandwidth between connected components. In terms of prioritization of resource allocation, one application might be highly significant from the overall enterprise perspective, while another application is not. For example, a high priority application might provide critical financial transfers between client accounts, while a lower priority application might provide relatively unimportant file downloads for employees sharing the same network.
In existing systems, DiffServ (DIFFerentiated SERVices) attempts to address this problem. DiffServ is a method for adding quality of service (QoS) to IP networks. Operating at layer 3 of the OSI (Open System Interconnection) model, DiffServ uses the IP Type of Service (ToS) field as the DiffServ byte (DS byte). DiffServ, as well as other existing systems using VLAN-tag (Virtual Local Area Network-tag) priority bits in the packet header, provide some packet prioritization, as well as some definition of delay requirements. However, these systems have significant drawbacks. For example, in the case where a wireless voice application runs on a wireless phone or wireless PDA (Personal Digital Assistant), voice data received from the wireless device is packetized and transmitted over a data network to a destination end station, such as another wireless device. Depending on the loss and delay between the communicating end stations, the wireless voice application may run successfully or fail. However, the wireless voice application can't do anything to control the end to end loss or delay across the enterprise network, other than setting DiffServ bits in the data packets (assuming they are IP packets). DiffServ can't address end-point to end-point service requirements, since internetworking devices typically do not consider DiffServ settings when they make path determinations. For example, a wireless device or enterprise application can't use DiffServ to require the network to offer 20 mSec delay with a 10% acceptable packet loss rate. Accordingly, there is nothing to prevent the enterprise network from operating such that packets are re-routed to avoid a dynamically detected point of network congestion causing an 8% packet loss, even when the delay resulting from the re-routing increases the overall end to end delay to 40 mSec. Thus re-routing of data may occur even if it is detrimental to the wireless application. Such problems result at least in part from the fact that internetworking devices such as routers and/or switches do not make path determinations based on the value of the DiffServ bits.
Existing enterprise networks are generally designed to transfer packets from point A to point B within the enterprise without taking into consideration enterprise application service needs. Accordingly, a forwarding device might not define different queuing or networking paths for two different packet flows with different requirements, but destined for the same end station or subnet. QoS is typically supported on a forwarding domain basis. While it may be convenient on a platform architecture basis to support QoS within a single forwarding domain, it doesn't enable the end-to-end service definition capabilities needed by enterprise applications.
An example of an existing communication protocol providing bandwidth reservation is RSVP-TE (ReSerVation Protocol with Traffic Engineering). RSVP is a communications protocol that signals a router to reserve bandwidth for real-time transmission. RSVP-TE creates traffic engineered paths that solve bandwidth related issues. However, currently, RSVP-TE requires expensive routers and does not span across forwarding domains. Accordingly, RSVP-TE also does not enable enterprise application programs to define end point to end point service requirements. Moreover, even if networks are deployed with costly RSVP-TE routers, RSVP doesn't offer certain services at a network level because RSVP itself is run at an individual internetworking platform level.
An example of an existing communication protocol for providing communication services using the Internet as a backbone network is MPLS (MultiProtocol Label Switching). MPLS enables routing of packets over the Internet. MPLS uses labels, or tags, containing forwarding information, that are attached to IP packets by a router sitting at the edge of the MPLS forwarding domain, known as a label edge router (LER). Generally speaking, LERs perform packet analysis and classification before the packet enters the core of the MPLS network. Routers within the MPLS forwarding domain core, known as label switch routers (LSRs), examine the added label and forward the packet. MPLS can ensure that all packets in a particular flow take the same route over an MPLS forwarding domain. However, since MPLS operation is enabled by LERs, it does not provide an application program specific control interface that would enable enterprise application programs to control parameters necessary to appropriately support their operation across forwarding domains within an enterprise network. Moreover, MPLS itself does not conveniently support dynamic route control, and cannot easily provide the scalability necessary for enterprise networks, which must be designed to grow conveniently in terms of adding devices and applications.
The above discussion describes some of the shortcomings of existing enterprise data networks with regard to supporting enterprise application programs. Enterprise application programs do not receive independent network related service guarantees from the enterprise network, other than end to end connectivity. Many existing enterprise applications are non-real-time data applications. However, as converged data and voice networks emerge, and the next generation of data applications put more requirements on enterprise networks, there is a growing need for a new system that can meet the specific needs of enterprise applications with respect to application specific service definitions provided on an end to end basis across the entire underlying enterprise network.